Network engineers know the frustration: Border Gateway Protocol (BGP) says traffic should take one path, but traceroutes, latency spikes, or outage symptoms tell a completely different story. That gap—between what the control plane (BGP's routing decisions about where traffic should go) intends and what the data plane (the actual forwarding path traffic takes) delivers —is exactly what this post addresses. We deployed BGP monitors directly at our Cloud Agent locations to close it, and here we explain what that means architecturally and the additional correlated visibility it now brings customers.
ThousandEyes Cloud Agents
ThousandEyes Cloud Agents are more than one thousand globally distributed, software-based monitoring vantage points, which are managed and maintained by Cisco ThousandEyes. They are strategically deployed in over 270 cities worldwide, including locations within Internet service providers, Internet exchange points, and major cloud providers such as AWS, Google Cloud, Azure, and Alibaba. These agents provide an "outside-in" perspective by simulating end-user experiences from the edge of the Internet without requiring customers to deploy any hardware or software themselves.
What Cloud Agents do is generate their own synthetic test traffic, including network, DNS, web, transaction, and voice tests, to continuously monitor the availability and performance of applications, networks, and services across the public Internet and cloud environments. They provide detailed insights into network paths, application behavior, and routing, enabling hop-by-hop analysis and multi-layered views of performance. This allows organizations to detect issues proactively, even when problems occur far from their own infrastructure.
Cloud Agents are useful because they offer extensive Internet-scale coverage with hundreds of ready-to-use global vantage points, enabling organizations to benchmark ISP, cloud, and regional performance with verifiable data. They help simulate real-world transactions and API calls, not just simple pings or uptime checks, providing a realistic view of user experience. This visibility is critical for troubleshooting issues such as slow SaaS logins, API latency, or routing detours that might be invisible from within an enterprise network. Additionally, Cloud Agents support use cases like benchmarking cloud migrations, holding providers accountable with independent performance data, and guiding infrastructure decisions such as multi-cloud strategies or CDN adoption.
ThousandEyes BGP Monitoring
ThousandEyes BGP monitors are privately operated routing infrastructure that provides detailed, real-time visibility into BGP routing data across the Internet. They enable organizations to monitor network reachability, detect routing changes, and identify security threats such as route hijacks and leaks. A separate engineering post covers the BGP monitoring of the infrastructure and architecture in detail using ThousandEyes.
What BGP Monitoring Helps Us Provide
-
Collect and visualize BGP routing information, showing autonomous system (AS) paths and routing changes.
-
Detect and alert on, on-route hijacks in near real-time and infer routing anomalies such as route leaks and route flapping through analysis of AS path data.
-
Integrate BGP data with other network performance metrics to correlate routing events with latency, packet loss, and other conditions.
-
Alert on Resource Public Key Infrastructure (RPKI) violations.
-
Support network operators in monitoring the impact of routing policy changes, validating traffic engineering, and optimizing multi-homing and peering arrangements.
-
Export event-driven BGP metrics via OpenTelemetry for integration with other monitoring and operational tools.
Why BGP Routing Visibility Matters
-
Comprehensive Network Visibility: Provide a multi-perspective, real-time view of Internet routing, including from within the customer’s own network.
-
Proactive Security: Enable early detection and alerting of BGP hijacks, leaks, and suspicious routing behavior, reducing network vulnerabilities.
-
Performance Optimization: Help identify suboptimal routing paths and validate routing policies by correlating routing data with network performance.
-
Reliable Operations and Business Continuity: Facilitate rapid assessment of routing changes, support disaster recovery, and maintain service availability.
-
Simplified Troubleshooting: Visualize routing paths and changes to quickly pinpoint issues affecting reachability and performance.
-
Enhanced Collaboration: Real-time data sharing and detailed routing topologies simplify issue resolution with vendors and service providers.
We currently have 270+ active BGP monitors in production, present in 96 cities and 49 countries worldwide. We will keep deploying BGP monitors in cloud agent locations, with the goal of covering as many parts of the AS Graph (the topology of interconnected autonomous systems that make up the routable Internet) as possible.
When BGP Routing Diverges From Actual Traffic Paths
On the Internet, the paths that traffic follow are not always determined solely by BGP because other factors influence route selection and traffic forwarding. Two key concepts that explain this behavior are Administrative Distance (AD) and tunnels.
Administrative Distance (AD)
Routers often receive directions to the same destination from multiple sources simultaneously—a static route configured by an operator, an OSPF update from within the network, and a BGP announcement from a peer might all point to the same prefix. Administrative Distance (AD) is how the router breaks that tie, assigning a trustworthiness score to each source, so it knows which one to act on.
Cisco IOS for example defines this hierarchy explicitly—a static route will always override an eBGP route, which in turn overrides an iBGP route, with other vendors implementing equivalent mechanisms under different names. The full hierarchy is in Cisco’s documentation but the consequence for our purposes is the same regardless of platform: Even when BGP has selected what it considers the optimal path, it can be overridden entirely by a lower AD route—and BGP has no visibility into that decision. Importantly, AD influences which route gets installed in the forwarding table, but has no effect on BGP's own internal path selection algorithm.
Tunnels
Tunnels compound this further, steering traffic through explicitly defined or dynamically computed paths that may not align with BGP's best path selection:
Traffic Engineering and Explicit Path Control
-
MPLS Traffic Engineering (TE) tunnels, including RSVP-TE and Segment Routing TE (SR-TE), allow the network to establish Label Switched Paths (LSPs) that explicitly control the route traffic takes through the network. These tunnels can override the default BGP best path by steering traffic along pre-determined paths based on bandwidth, latency, or other constraints.
-
The headend router of a TE tunnel controls the path, which may not align with the BGP best path. This means traffic forwarding decisions are influenced by tunnel configurations rather than BGP route selection alone.
-
Automated steering mechanisms use BGP community tags to bind traffic to specific TE tunnels, enabling traffic to be forwarded down tunnels selected by policies rather than BGP path preference. This is often called BGP-driven traffic engineering.
PCE-Initiated and On-Demand Tunnels
-
Path Computation Elements (PCEs) can dynamically instantiate tunnels and optimize Label Switched Paths (LSPs) without the router verifying or computing the path itself. This dynamic tunnel creation can steer traffic independently of BGP’s best path calculation.
-
On Demand Next-Hop (ODN) mechanisms bind BGP next-hop addresses with specific tunnel colors (identifiers that associate a BGP next-hop with a particular tunnel path) to steer traffic dynamically, further decoupling forwarding decisions from BGP path selection.
Layer 2 and Layer 3 Tunnels
-
Layer 2 tunnels encapsulate traffic and can create virtual point-to-point links that bypass normal IP routing decisions. Traffic inside these tunnels follows the tunnel path, which may not correspond to the BGP-determined path.
-
Layer 3 tunnels such as IPsec or Generic Routing Encapsulation (GRE) can also encapsulate traffic and route it through specific endpoints, overriding BGP path decisions by forcing traffic through the tunnel endpoints.
Impact of Tunnel Groups and Preferences
-
In SD-WAN and other overlay networks, tunnels are grouped and assigned preferences or weights that influence traffic distribution. These preferences can override BGP path selection by directing traffic over preferred tunnels regardless of BGP best path metrics.
In each of these cases, the result is the same: traffic follows a path that BGP alone cannot account for—which is precisely the visibility gap we set out to close.
Enhanced Control and Data Plane Correlation
Given these factors, a BGP monitor placed anywhere other than the exact vantage point of your cloud agent is answering a subtly different question. It sees the control plane as it looks from its location, on its upstream, in its address space—not yours. A cloud agent alone tells you what the data plane experienced, but without the matching routing context. Because our BGP monitors are software-defined, we have the flexibility to bring both together: we can deploy them precisely where our cloud agents are, sharing the same upstream, the same routed prefixes, and therefore the same traffic engineering policies.
At each Cloud Agent location, the monitoring software runs as a set of isolated instances—one per active measurement. To add BGP monitoring capability without disrupting existing measurements, we dedicated one of these instances at each location to serve as a BGP monitor, with the following requirements:
-
The Internet connectivity provider at the location must support dual-stack capabilities (both IPv4 and IPv6).
-
The monitor must receive full BGP tables from the same provider that supplies connectivity to the location.
-
The IPv4 and IPv6 addresses of the BGP monitor must belong to the same prefixes as the other monitoring instances at that location, helping to ensure that the same BGP traffic engineering policies apply across the applicable instances.
Why Deploy BGP Monitors in Cloud Agent Locations
By ensuring these requirements are met, we can provide customers with a direct correlation between control plane and data plane measurements—BGP routing tables and path announcements as seen by the collocated BGP monitor—and data plane data—network path traces, latency, and packet loss as generated by the collocated cloud agent—from the same geographic location for the same routed prefix. This enables customers to identify when the previously mentioned factors affect traffic routing and cause deviations from expected BGP behavior.
For example, in the event of outages, such insights help conduct root cause analysis more quickly and accurately. Such detailed correlation helps isolate whether issues stem from control plane problems (e.g., routing protocol failures) or data plane issues (e.g., forwarding errors), streamlining troubleshooting efforts.
Status and Next Steps
As part of our ongoing expansion, we have deployed 102 BGP monitors across 51 cloud agent locations, covering 40 cities, nine countries, and four continents, connected to 16 different ASNs. Customers running tests from those cloud agent locations already have access to correlated control and data plane data from the same vantage point, with coverage continuing to expand as we add monitors to further cloud agent locations, broadening our footprint across the AS graph and the routing diversity it represents.
Current and Planned Enhancements:
In the ThousandEyes UI, collocated BGP monitors will be identifiable alongside their associated cloud agent locations. When customers run cloud agent tests, the "Collect BGP Data" option is currently selected by default, which includes data from all public BGP monitors. For customers running tests from cloud agent locations with collocated BGP monitors, the correlated control and data plane data from those monitors is already accessible today. We plan to continue to develop the UI to make this correlation easier to navigate and act on, with improvements to how collocated monitors are surfaced and selected within existing test workflows.
Many of the products and features described herein remain in varying stages of development and will be offered on a when-and-if-available basis. The delivery timeline of these products and features is subject to change at the sole discretion of Cisco, and Cisco will have no liability for delay in the delivery or failure to deliver any of the products or features set forth in this document.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company.
